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Per realizzare 1' interlavoro nell'ambito di un insieme di reti 
del tipo Content Delivery Network CDN (CDNl, CDN2) si utilizzano 
componenti di interfaccia destinati ad essere associati ciascuno 
ad una rete (CDNl) dell' insieme ed a cooperare in funzione di 
Content Internetworking Gateway (CIG) con almeno un componente 
omologo associate ad un'altra rete (CDN2) dell' insieme- Nei 
suddetti componenti di interfaccia. (CIG) si raccolgono 
informazioni di instradamento relative all' associazione fra i 
contenuti e le cache che li contengonb nell'ambito dell' insieme 
di reti. Tali informazioni di instradamento sono trasferite dai 
suddetti componenti di interfaccia (CIG) ai servizi di directory 
name o domain name server (DNS) delle rispettive reti. L' accesso 
dei client ai contenuti delle reti collegate in internetworking 

(CDNl, CDN2) si realizza cosi attraverso il servizio di directory 
name o domain name server (DNS) della rispettiva rete. 

(Figura 2) 
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TESTO DELLA DBSCRIZIO NB ^ 
' ■ oS 3 

La presente invenzione si riferisce, in g O 

generale, alle tecniche di interlavoro tra reti, 0=="^ 
correntemente indicate come tecniche di '^M 

M O 

"internetworking" . 

In termini generali, I'obiettivo di fondo 
dell ' internetworking ^ la cooperazione e 
1' interoperability di sistemi elementari (visti come 
scatole nere o «black box") al fine di costituire un 
macrosistema tale da presentare le stesse 
caratteristiche dei sistemi costituenti con 
1 ' aggiiinta di una serie di vantaggi . 

In primo luogo, quando due o pid entity 
amrainistrative differenti raggiungono un accordo di 
internetworking, queste estendono (nei limiti 
contrattuali) i rispettivi bacini di utenza, senza 
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ulteriori spese di cablaggio o comiinque di carattere 
strutturale. E' ragionevole poi pensare che la 
qualita di sei-vizio perceplta dall'utente finale 
risulti accresciuta per le tnaggiori dimensioni della 
rete di rif eritnento . 

Nel caso specifico delle cosiddette Content 
Delivery Network o CDN si registra inoltre ion 
arricchimento ed una diversif icazione in termini di 
contenuti offerti. 

Per la sua stessa natura, vma soluzione di 

internetworking richiede la presenza di componenti 03 >< 

di interfaccia che, dal lato del sistema elementare 29 

< Q 

(nella fattispecie, la singola CDN) , abbia la O □ 



completa visione dell ' evoluzione delle q 

caratteristiche statiche e dinamiche e dal lato del ^% 
"resto del mondo" (ossia dal lato della altre reti 
CDN comprese nell ' insieme di reti collegate in 
internetworking, ciod, in ultima analisi, dal lato 
peer), disponga di tutte e sole quelle informazioni 
necessarie a realizzare una comunicazione proficua 
inter- sistema. Con il termine proficua si vuole 
intendere efficace ma anche sicura ed affidabile, 
con tutti gli accorgimenti che una. soluzione di 
questo tipo puS conportare. 

La materia d in corso di regolamentazione, cosi 
come document at o, ad esempio, dalle seguenti 
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proposte di standard pubblicate in atnbito IETF 
(Internet Engineering Task Force) e reperibili sul 
sito web di tale organizzazione : 

"A Model for CDN Peering", di M. Day, B. Cain, 
G. Tomlinson e P. Rzewski, maggio 2001; 

**Content Internetworking Architectural 

Overview"; di M. Green, B. Cain, G. Tomlinson, S. 
Thomas e P. Rzewski, tnarzo 2001; 

"Known Mechanisms for Content Internetworking", 
di F. Douglis, I. Chaudhri e P. Rzewski, novembre 
2001. 

I suddetti componenti di interfaccia vengono 
denominati Content Internetworking Gateway o CIG. I 
CIG hanno una visione completa dell • ambiente intemo 
della propria CDN, mentre percepiscono i dati 
relativi agli ambienti remoti attraverso protocolli 
per lo scambio di informazioni denominate 
informazioni di "advertisement" . 

Da un punto di vista astratto, un CIG deve 
realizzare 1 • instradamento delle richieste (ciod 
svolgere la funzionalita di request-routing) , sulla 
base di tutta una serie di informazioni che gli 
giungono dai moduli preesistenti intra-CDN (sistema 
di distribuzione e sistema di monitoraggio) e dai 
dispositivi remoti loro pari. 



Secondo le proposte di standard citate in 
precedenza, d previsto che il CIG svolga nei 
confronti dei client la fionzione di instradamento 
delle richieste di contenuti. 

In particolare, ricevuta da un client un 
richiesta di un certo contenuto, e verificato che 
tale contenuto richiesto d disponibile nell'arabito 
della propria CDN, il CIG invia al client 
1' identificativo corrxspondente alia cache in cui si 
trova il contenuto richiesto II CIG in questione e 
poi in grado di svolgere la stessa funzione di 
instradamento nel caso in cui il contenuto richiesto 
sia ospitato su una cache di un'altra CDN. 

Questa situazione fa si che, quando piii reti CDN 
sono collegate fra lore in internetworking, ai CIG 
vengono attribuite le funzioni di risoluzione degli 
indirizzi e di instradamento delle richieste di 
contenuti, funzioni che a livello di rete internet 
vengono demandate ad altri organi di rete, in 
particolare con coinvolgimento del cosiddetto DNS ( 
(Directory Name Service o Domain Name Searver) . 

Da cio deriva una sorta di sdoppiamento 
/duplicazione di funzioni che sta alia base di 
diversi inconvenient i . Questi sono legati, fra 
I'altro, alia necessita di assicurare una corretta 
sincronizzazione fra CIG ed apparecchiature della 



rate internet ed al fatto che la richlesta di un 
determinate client viene trattata in modo diverse a 
seconda che tale richiesta coinvolga owero non 
coinvolga il livello CDN. 

La presente invenzione si prefigge lo scopo di 
superare tali inconvenienti . 

Secondo la presente invenzione tale scopo viene 

raggiunto grazie ad un procedimento avente le 

caratteristiche richiamate nelle rivend±cazioni che 

seguono. L' invenzione riguarda anche un 

corrispondente sistema di reti CDN collegate in !f 3 

O o 

internetworking nonche un relative component e di ;< ^ 

interfaccia o CIG. 

L' invenzione sar^ ora descritta, a puro titolo m2 
di esempio non limitativo, con riferimento ai ^ 
disegni annessi, nei quali: 

- la Figura 1, illustra in generale i criteri 
di organizzazione dell ' interlavoro fra due reti CDN, 

- la Figura 2 illustra la generale struttura di 
un Content Internetworking Gateway o CIG operante 
secondo 1 ' invenzione , 

- le Figure 3 e 4 illustrano diverse modalita 
di instradamento delle richieste intra-CDN ed inter- 
CDN, 
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- le Figure 5 a 7 illustrano, a vari livelli di 
approf ondimento, diagrammi di contesto tipici di xin 
CIG realizzato secondo 1' invenzione, 

- la Figura 8 rappresenta I'automa a stati 
finiti di un corrispondente CIG, 

- la Figura 9 § un diagramma temporale relative 
all'apertura di una corrispondente sessione, e 

- le Figure 10 a 13 illustrano i formati di 
vari messaggi scatnbiati nell'impiego di un CIG 
secondo 1 ' invenzione . 

Lo schema della figura 1 illustra la ^ x 

collocazione di due Content Internetworking Gateway ^ O 

S ^ 

(nel seguito, per brevity, CIG) destinati a 0 5T; 

consentire, in appoggio ad un server di origine 
(Origin Server) OS, lo scambio di informazioni di 
^'advertisement'' nell'ambito di un insieme formato da 
due content delivery network CDNl e CDN2 . 

Ciasciina CDN e qui rappresentata come 
costituente un rispettivo dominio amministrativo con 
servizio di directory name o domain name server (in 
iDreve, DNS) , centre di gestione, memorie cache e 
collegamenti ai terminali con fimzione di client. 

La figura 1 evidenzia il ruolo dei CIG nel 
processo di internetworking. Una delle 

caratteristiche peculiari di un CIG ^ il grado (o 
livello) di integrazione, inteso come parametro. 
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rispetto ai moduli gia present! ed operant! 
all'!nterno d! una CDN. 

Propr!o !n dipendenza di tale parametro si pu6 
valutare la maggiore o minore efficacia delle 
relative funzionalit^ di interf accia. 

La figura 2 il lustra in maniera sintetica i 
component! di interfaccia che costituiscono, nella 
forma di attuazione al momento preferita, un CIG 
secondo 1 ' invenzione . 

In particolare il CIG in questione d costituito 

da: 

~ un primo modulo di interfaccia, definite 
Request -Routing Interface o RRI , che si occupa dello 
scambio di inf oirmazioni con i CIG remoti, secondo le 
specifiche del protocollo CNAP (meglio descritto nel 
seguito) , 

- un secondo modulo di interfaccia, definito 
DNS Interface o DNSI, che si interfaccia con il DNS 
della rete CDN alia quale il CIG appartiene, 

un terzo modulo di interfaccia, definito 
Distribution Information Interface o DII, che 
reperisce le informazioni sulla disponibilit^ dei 
contenuti dal sistema di distribuzione della rete 
CDN alia quale il CIG appartiene , 

- un quarto modulo di interfaccia, definito 
Monitoring Information Interface o Mil, che 
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intenragisce con il sistema di monitoraggio, 
inf ine, 

un modulo centrale, denominato Request - 
Routing Process o RRP, che raccoglie ed elabora 
tutte le informazioni ricevute in modo da realizzare 
I'instradamento delle richieste: quest 'ultimo modulo 
rapparesenta il nucleo del CIG. 

Si apprezzera che 1 ' architettura sopra 
descr-itta, seppur . pref erita, non e da ritenersi del 
tutto imperativa e vincolante, almeno per quanto 
riguarda la presenza del terzo e del quarto modulo 
di interfaccia descritti in precedenza. 

In merito al protocollo CNAP si puo utilmente 
consialtare il documento "Content Network 
Advertisement Protocol (CNAP)" di B. Cain, O. 
Spats check, L. Amini, A. Barbir, M. May e D. Kaplan, 
novembre 2001, anch'esso reperibile sul sito web 
dell' IETF. 

Sintetizzando, si puo asserire che il CIG d 
costltuito da un modulo centrale, dove risiede 
''1'in.telligenza" del dispositive, e da un certo 
numero di moduli di interfaccia tra il CIG stesso e 
I'inf rastruttura preesistente . 

In relazione alle tecniche di instradamento 
delle richieste la soluzione descritta rientra in 
quelle basate sulla tecnologia DNS. 
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In proposito si possono ipotizzare due scenari 
verositnili di internetworking, illustrati 

utilizzando il f oarmalismo del diacfaramma tracciato 
degli event i (event trace diagram) . 

In f igura 3 , e riportato uno scenario di 
content routing, per cosi dire, classico, intendendo 
con questo termine il processo di instradamento 
standard all 'interne di \ina CDN (basata sulla 
tecnologia DNS), bench^ 1 ' aggiomamento delle 
tabelle del DNS sia g±k deputato al CIG mediante il 
modulo DNS I . 

Procedendo in questo modo risulta agevole 
estendere 1 • esempio al caso di internetworking 
ef f ettivo- 

Le etichette e i versi delle frecce riprodotte 
nelle figure aiutano a comprendere come si 
susseguano realmente gli eventi: un utente effettua 
una richiesta di contenuto, rivolgendosi al sistema 
DNS, che funziona in modalitS standard. Il DNS 
risponde con I'indirizzo IP del siarrogato ottimo, 
secondo le politiche di instradamento in quel 
momento in vigore. Periodicaraente il CIG aggiorna le 
tabelle del DNS, sulla base delle informazioni 
ricevute dal sistema di distribuzione e di 
monitoraggio; si ricordi che, in questa prima 
ipotesi, il sistema per cosi dire ^^isolato" . 



Diversamente, nella situazione della figura 4, 
i server surrogati selezionati appartengono ad un 
altro dominio amministrativo, owero CDN. Si nota 
subito, tuttavia, che la dinamica appare 
sostanzlalmente simile a quella dell " esempio 
precedente. Ora, infatti, come gia accadeva prima^ 
il client interroga il DNS il quale risponde con 
I'indirizzo IP del server surrogato ottimo. Ci6 che 
Gambia d la procedura di aggiomamento e di 
reperimento delle inf oarmazioni (update) • La sezione 
centrale, in cui compaiono f recce a doppio verso, 
indica lo scambio periodic© di inf ormazioni di 
instradamento che awiene tra entity gerarchicamente 
pari grado (peer) , i CIG, secondo le convenzioni e 
le specif iche del protocollo CNAP. Questo tipo di 
inf ormazioni , del tutto analoghe a quelle intra-CDN, 
consentono ad un CIG 1 • aggiornamento delle tabelle 
del DNS, sulla base ^-di una piu ampia gamma di 
informazioni rispetto a quanto pu6 awenire nelle 
architetture note. 

I ruoli dei moduli component i un CIG operant e 
secondo I'invenzione saranno ora descritti 
utilizzando il formalismo indicate con I'acronimo 
DFD (Data Flow Diagram) . 

L'approccid di piu alto livello consiste in un 
diagramma cosiddetto ' di contesto (context diagram) . 



Esso rappresenta le interazioni tra il CIG nella sua 
integrita ed il "'mondo esterno" . Come si osserva, il 
CIG appare come un'unica entita, capace di 
interagire con il resto del mondo. 

Esso si occupa dell ' ins tradamento delle 
richieste sulla base delle informazioni che 
provengono dalle altre entita con cui comunica. Piu 
in particolare esso riceve informazioni dai peer, 
dal sistema di distribuzione e dal sistema di 
monitoraggio locali, e, dopo averle elaborate, 
aggiorna le tabelle del DNS e I'archivio dei file di 
log. 

A questo punto e possibile osservare il sistema 
di request -routing ancora piii da vicino, effettuando 
una scomposizione in sottosistemi e rappresentando 
le funzionalita a diversi livelli di dettaglio. Due 
espansioni successive sono mostrate rispettivamente 
in figura 6 e in figura 7. 

In particolare, dalla figura 6, corrispondente 
ad un primo livello di dettaglio, appare evidente 
come si comportino i processi di interfaccia: si 
tratta di moduli ""cuscinetto" che comunicano da un 
lato con il processo centrale, dall'altro con il 
mondo esterno. 

La figura 7 illustra invece le funzionalita 
proprie del nucleo RRP. Esso riceve i dati dal resto 
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del mondo tramite le interfacce, estrae 

1 ' inf ormazione utile sullo stato delle cache e/o dei 

contenuti, valuta la necessita di effettuare un 

aggiornamento, che realizza eventualtnente 

modificando il proprio database, le tabelle del DNS 

e I'archivio dei file di log. Infine, se necessario, 

inoltra il inessaggio verso i suoi pari (peer) , 

attraverso 1 » interf accia di request -routing RRI. 

L ' interf accia di request -routing RRI 

rappresenta il modulo di interfaccia con il resto 

del mondo* In questo senso si tratta del modulo piu q ^ 

importante della procedura di internetworking, ^ ^ 

O rJ' 

perch^ direttamente implicato nella comunicazione Z ^ 

N4 O 

mter-CDN; comunicazione che, cosi come indicate in M h— 

CD < 

precedenza, awiene secondo le convenzioni del 
protocollo CNAP, studiato appositamente a questo 
scopo . 

Compito di questo modulo e la traduzione dei 
messaggi dal formato CNAP (inter-CDN) ad un formato 
comprensibile al processo centrale del CIG (intra-v^"^^^-^^'^^^ 



CDN) , I'RRP. II protocollo CNAP richiede che vengaii4> , 
inizialmente specificate (e poi periodicamentf^:,^. 
aggiornate) una serie di inf ormazioni, per cosiX^^c'^J 
dire, statiche, relative f ondamentalmente alle 
caratteristiche topologiche del sistema di 
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internetworking. Ad esempio^ possono essere 
richiesti : 

- 1 ' identif icativo CNAS locale (cioe della CDN 
proprietaria del CIG in questione) ; 

- I'indirizzo IP della macchina del CIG locale; 

gli identif icativi CNAS dei sistemi 
interconnessi in remoto (peer) con cui si intendono 
intarattenere relazioni di internetworking; 

- gli indirizzi IP delle macchine dei CIG 

remoti corrispondenti ai sistemi di cui al punto 

precedente; q ZD 

as: P 

- i livelli di confidenza inter-CNAS; e ^ Z, ^ 

O riT: 

- un coefficiente numerico indicante il ""peso", Z ^ «« 

O 

m condizioni statiche dei singoli collegamenti (in 



pratica e un analogo della distanza geografica del 
collegamento) . 

II protocollo prevede la possibilita di 
diversif icare le relazioni contrattuali di 
internetworking, con 1 ' introduzione di livelli di 
confidenza. In altre parole, prima di diffondere 
informazioni di disponibilit^ a riguardo di un 
contenuto verso un CIG remoto, il CIG locale 
verlfica che, sulla base del contratto stipulato, 
tale CIG sia abilitato a recepire 

quell ' inf ormazione . 



ZD Z 
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Le connessioni CNAP, cosi come richiesto dall • 
lETP nei requisiti per i protocolli di 
internetworking, si appoggiano a livello trasporto 
su un protocollo affidabile ed orientato alia 
connessione: si pu6 trattare ad esempio del 
protocollo TCP (Transmission Control Protocol) , di 
utilizzo corrente in contesto internet. 
Si riportano di seguito le operazioni logiche 
necessarie per 1 • instaurazione di una sessione CNAP. 

Ci6 viene fatto con specifico riferimento alio 

schema di automa a stati f initi del CIG illustrato ^ 

O o 

nella f igura 8 . < Q 

11 CIG si trova, all'istante iniziale, in uno Z 3 

stato, definite IDLE, in cui la sessione CNAP non m O 

sussiste e nessuna entita si e ancora mossa af f inche ^ < 

tale stato muti. Quando esso intende stabilire una 
sessione CNAP con un CIG remote, esso invia verso 
quest 'ultimo un messaggio OPEN ed entra nello stato 
OPENSENT . 

II CIG remote, anch'esso inizialmente nello 
stato IDLE, riceve la richiesta di apertura di una 
sessione CNAP. Esso risponde con un messaggio 
KEEPALIVE e passa nello stato OPENCONFIRM. 
Si presentano due casi. 

Nel primo caso, il CIG originario riceve il 
messaggio KEEPALIVE entro un intervallo di tempo 



15 



prefissato: in tal caso entra nello stato READY e si 
mette in attesa di inviare messaggi di advertisement 
(cioe messaggi che portano informazione utile, non 
solo metadati, come accade per i messaggi 
d' inizializzazione) . 

Nel secondo caso, il time-out prefissato scade 
prima che il CIG originario abbia ricevuto il 
messaggio KEEPALIVE atteso: in tal caso esso ritoma 
nello stato IDLE ed il tentativo di comunicazione 
fallisce. In generale, un messaggio NOTIFY render^ 
nota I'anomalia alle due contropart±. 

II CIG remote, avendo inviato con successo il O O 

messaggio KEEPALIVE, passa anch'esso nello stato g — 

READY e si mette in ascolto di messaggi di 

M O 

advertisement da ricevere. S Z 

CO < 

La ricezione di un messaggio NOTIFY comport a il 
passaggio del CIG nello stato IDLE. Come si pu6 
facilmente desumere da quanto detto sopra, la 
connessione CNAP e attiva ed effica.ce se entrambi i 
CIG coinvolti entrano nello stato READY. 

In figura 9, si riproduce la. successione di 
stati che caratterizzano 1 ' apertura. di una sessione 
CNAP, mettendo in evidenza I'evoluzione temporale 
degli event i . 

Per quanto riguarda il formato dei messaggi 
scambiati tra il nucleo RRP e 1 ' interf accia di 
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request -routing RRI d possibile assegnare a tali 
messaggl il formato riportato in figura 10. 

II significato dei campi del messaggio d di 
seguito specif icato : 

URL: d I'URL che identifica il contenuto cui si 
riferisce il messaggio; 

IP: d I'indirizzo IP della cache che 
distribuisce il contenuto; 

CNAS ID: d 1 ' identif icativo della CDN 
proprietaria della cache; 

CACHE STATE: e lo stato della cache; 
CONTENT STATE: rappresenta lo stato del 
contenuto presente in cache; 

TTL: e il tempo di vita dell • inf ormazione di 
instradaimento . 

L • ±nterf accia di monitoraggio Mil d il modulo 
che realizza 1 ' interf accia tra il nucleo RRP ed il 
sistema di monitoraggio locale, cioe afferente alia 
CDN proprietaria del CIG. Le informazioni che esso 
deve essere in grado di trasferire all 'RRP sono 
relative alio stato delle cache della CDN, dove per 
stato s± intende una quantif icazione delle risorse 
disponibili. 

In quest ' ottica, il formato di un messaggio 
proveniente dall ' interf accia di monitoraggio Mil pud 
assumere I'aspetto mostrato in figura 11. 
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I campi del messaggio sono cinque ed assumono 
il seguente significato: 

IP: indirizzo IP della cache cui si riferisce 

11 messaggio; 

CPU: percentuale di CPU utilizzata dalla cache; 
MEM: percentuale di RAM utilizzata dalla cache; 
DISC: percentuale di utilizzo dei dischi della 
cache ; 

USERS: percentuale del numero di utenti 
connessi (in relazione alia capacita massima di 
servizio della cache in questione) . 

I parametri di cui si d detto sono gli 
indicatori prestazionali classici con cui si 
valutano le condizioni di utilizzo delle cache. I 
messaggi di questo tipo vengono passati all'RRP ad 
intervalli di tempo regolari. 

L' interf accia di distribuzione DII d il modulo 
di interfaccia tra il sistema di distribuzione e il 
nucleo RRP del CIG. L' interfaccia DII raccoglie 
informazioni relative alia presenza ed alia 
disponibilita dei contenuti nelle cache. In figura 

12 d illustrate un possibile formato di un messaggio 
di questo tipo. 

II significato dei campi d il seguente: 

URL: g I'URL che identifica il contenuto cui si 
riferisce il messaggio; 
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CACHE: d la lista di indirizzi IP delle cache 
che dispongono di quel contenuto; 

CONFIDENCE LEVEL: rappresenta il livello di 
confidenza del contenuto; 

CONTENT AVAILABILITY: indica la disponibilitS o 
meno del contenuto; 

CACHE STATE: e lo stato della cache; 
TTL: indica il tempo di vita dell ' inf ormazione 
di instradamento. 

I livelli di confidenza associabili ai 
contenuti sono tre, ossia: 

basso - i contenuti possono essere scambiati 
con tutte le CDN interconnesse ; 

medio - i contenuti possono essere scambiati 
solo con le CDN che hanno sottoscritto un accordo di 
confidenza di livello MEDIO con la CDN xn possesso 
del contenuto; e 

alto - i contenuti possono essere scambiati 
solo con le CDN che hanno sottoscritto un accordo di 
confidenza di livello ALTO con la CDN in possesso 
del contenuto. 

L' interf accia DNS, indicata con DNSI e il 
modulo di interfaccia che deve comunicare con il 
server DNS, in modo tale da poterne aggiornare le 
tabelle. Un possibile formato dei messaggi utili a 
questo scopo d riportato in f igura 13 . 
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II significato dei relativi campi e il 
seguente : 

OP: rappresenta I'operazione da eseguire sulla 
tabella ciel DNS (sono disponibili due operazioni, 
add e delete; 

REG TYPE: indica il tipo di registro; 

DOMAIN NAME: indica il nome del dominio cui si 
riferisce il messaggio; 

IP: d I'indirizzo IP della cache ottima per 
servire 111 dominio di cui sopra; 

X 

TTL: rappresenta il tempo di vita del registro. ^ 

In altemativa, il campo DOMAIN NAME pud < O 

O ^ — • 

contenere 1 ' intero URL del contenuto a cui si Z ^ 

riferisce il messaggio. In questo modo il DNS e nJ R 

messo in condizioni di identif icare direttamente la < 
cache ottima per I'erogazione (delivery) del 
contenuto . 

II modulo di request -routing RRP e, come si e 
gia detto, il nucleo del sistema. Esso ha il compito 
di elaborare le informazioni che gli gixangono dai 
moduli di interfaccia di cui si d parlato sopra, di 
aggiomare, se necessario, le tabelle del DNS, 
attraverso 1 ' interfaccia DNSI, e di inoltrare, 
attraverso 1 ' interfaccia RRI, le informazioni stesse 
verso gli altri CIG. 
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Esso si occupa inoltre di gestire 1 • archivio 
dei file di log. Dovendo mettere il relative DNS in 
condizioni di svolgere la funzione di risoluzione 
degli indirizzi (cosi da rendere I'erogazione dei 
contenuti di fatto '^trasparente" rispetto alia 
presenza di un insieme di reti CDN collegate in 
internetworking) il nucleo RRP deve disporre di una 
struttura dati, in cui terra memoria dello stato 
della CDN locale e di quello delle CDN remote. Tale 
struttura dati deve dunque raccogliere ed 
organizzare le inf ormazioni relative ai contenuti 
disponibili nell'ambito del sistema di 

internetworking ed alle cache in grado di fornire 
tali contenuti. La definizione della struttura dati 
e periodicamente aggiornata dal modulo RRP, in 
maniera diversa a seconda del tipo di messaggio che 
di volta in volta ha sollecitato 1 ' aggiomamento . 

Naturalmente, fermo restando il principio 
dell' invenzione, i particolari di realizzazione e le 
forme di attuazione potranno variare rispetto a 
quanto descritto ed illustrate senza per questo 
uscire dall'ambito della presente invenzione. 



RIVENDICAZIONI 

!• Procedimento per realizzare 1 ' interlavoro in 
un insieme di reti del tipo Content Delivery Network 
CDN (CDNl, CDN2) , le reti di detto insieme essendo 
prowiste di rispettive cache, rispettivi servizi di 
directory name o domain name server (DNS) e 
rispettivi sistemi di distribuzione del contenuti 
verso rispettivi client, nonche dL± componenti di 
interfaccia (CIG) suscettibili di essere associati 
ciascuno ad una rispettiva rete (CDNl) fra le reti 
di detto insieme e di cooperare in funzione di 
content internetworking gateway (CIG) con almeno un 
componente omologo associate ad un' altra (CDN2) rete 
di detto insieme, il procedimento comprendendo 
I'operazione di raccogliere, in detti componenti di 
interfaccia (CIG) , informazioni cai instradamento 
relative all ' associazione fra dett± contenuti e le 
cache che li contengonp ed essendo caratterizzato 
dal fatto che comprende I'operazione di trasferire 
(DNSI) dette informazioni di instraciamento da almeno 
uno di detti componenti di interfaccia (CIG) al 
servizio di directory name o domain name server 
(DNS) della rispettiva rete, per ciai I'accesso dei 
client di detta rispettiva rete ai contenuti delle 
reti di detto insieme (CDNl, CDN2) si realizza 
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attraverso il servizio di directory name o domain 
name server (DNS) di detta rispettiva rete. 

2. Procedimento secondo la rivendicazione 1, 
carat terizzato dal fatto che nell'ambito di detto 
almeno uno di detti componenti di interfaccia (CIG) 
vengono svolte le operazioni di: 

- ricevere informazioni sullo stato delle cache 
e/o dei contenuti della rispettiva rete, 

- determinare I'esigenza di un aggiornamento di 
detti contenuti, e 

realizzare detto aggiornamento effettuando 
almeno \in' operazione scelta nel gruppo costituito 
da: 

- modifica della rispettiva base dati, 

- modifica delle tabelle del rispettivo servizio 
di directory name, 

- modifica dell ' archivio dei rispettivi file di 
log, e 

inoltro di un messaggio con richiesta di 
aggiornamento verso detto almeno un componente 
omologo . 

3 . Procedimento secondo la rivendicazione 1 o la 
rivendicazione 2, caratterizzato dal fatto che detti 
componenti di inter-faccia (CIG) comunicano fra loro 
tramite protocollo CNAP. 
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4. Sistema comprendente \m insieme di reti del 
tipo Content Delivery Network CDN (CDNl, CDN2) 
col legate fra loro in interlavoro, le reti di detto 
insieme essendo prowiste di rispettive cache, 
rispettivi servizi di directory name o domain name 
server (DNS) e rispettivi sistemi di distribuzione 
del contenuti verso rispettivi client, nonche di 
componenti di interfaccia (CIG) suscettibili di 
essesre associati ciascuno ad una rispettiva rete 
(CDNl) fra le reti di detto insieme e di cooperare 
in f lanzione di content internetworking gateway (CIG) ^ x 

con almeno un componente omologo associate ad § O 

< Q 

un'altra (CDN2) rete di detto insieme, detti O 5 

componenti di interfaccia (CIG) essendo configurati 

M O 

per raccogliere mformazioni di instradamento ^ Z 



relative all' associazione fra detti contenuti e le 
cacbe che li contengono, il sistema essendo 
caratterizzato dal fatto che almeno uno di detti 
componenti di interfaccia (CIG) e configurate per 
trasferire (DNSI) dette informazioni di 

instradamento al servizio di directory name o domain 
name server (DNS) della rispettiva rete, per cui 
I'accesso dei client di detta rispettiva rete ai 
contenuti delle reti di detto insieme (CDNl, CDN2) 
si realizza at traverse il servizio di directory name 
o domain name server (DNS) di detta rispettiva rete. 



24 



CO < 



# 



5. Sistema secondo la. rivendicazione 4, 
caratterizzato dal fatto che detto almeno uno di 
detti component i di interface la (CIG) e configurato 
per svolgere le operazioni di : 

- ricevere inf ormazioni svillo stato delle cache 
e/o dei contenuti della rispettiva rete, 

- determinare I'esigenza di un aggiornamento di 
detti contenuti, e 

realizzare detto aggiornamento effettuando 
almeno un' operazione scelta nel gruppo costituito 
da: 

- modifica della rispettiva. base dati, 

- modifica delle tabelle del rispettivo servizio 
di directory name, 

- modifica dell' archivio dei rispettivi file di 
log, e 

inoltro di un messagglo con richiesta di 
aggiornamento verso detto a.lmeno un componente 
omologo . 

6. Sistema secondo la rivendicazione 4 o la 
rivendicazione 5, caratterizzato dal fatto che detti 
componenti di interfaccia (CIG) comunicano fra loro 
tramite protocollo CNAP. 

?• Componente di interfaccia (CIG) per 
realizzare 1 ' interlavoro fra ireti del tipo Content 
Delivery Network CDN (CDNl, CDN2) comprese in un 
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insieme di tali reti (CDNl, CDN2) , dette reti di 

detto insieme essendo prowiste di rispettive cache, 

rispettivi servizi di directory name o domain name 

seirver (DNS) e rispettivi sistemi di distribuzione 

del contenuti verso rispettivi client, detto 

componente di interfaccia (CIG) essendo suscettibile 

di essere associato ad una rispettiva rete (CDNl) 

fra le reti di detto insieme e di cooperare in 

funzione di content internetworking gateway (CIG) 

con almeno un componente omologo associato ad 

im'altra (CDN2) rete di detto insieme, detto 

componente di interfaccia (CIG) essendo configurate o o 

per raccogliere informazioni di instradamento _ . 

O zi'^ 

relative all ' assocxazione fra detti contenutx e le 

M O 

cache che li contengono e caratterizzato dal fatto ^ ^ 

che comprende: 

- un primo modulo di interfaccia (RRI) per lo 
scambio di informazioni con detto almeno un 
componente omologo, 

- un secondo modulo di interfaccia (DNS I) per 
1' inter face lament o con il servizio di directory name 
(DNS) della rispettiva rete, e 

- un nucleo (RRP) per raccogliere ed elaborare 
le informazioni ricevute dal componente e realizzare 
1 ' instradamento delle relative richieste. 
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per cui detto component e di interfaccia (CIG) d 
suscettibile di trasferire, tramite detto secondo 
modulo di interfaccia (DNSI) , dette informazioni di 
instradamento al seirvizio di directory name o domain 
name server (DNS) della rispettiva rete. 

8. Componente secondo la rivendicazione 7, 

caratterizzato dal fatto che il componente e 

configurate per operare sotto il controllo di un 

sistema di monitoraggio e comprende: 

un terzo modulo (DII) per reperire 

informazioni sulla disponibilita dei contenuti dal ^ ^ 

sistema di distribuzione dei contenuti della O o 

rispettiva rete, e 

un quarto modulo di interfaccia (Mil) per 

M O 

interagire con detto sistema di monitoraggio ^ 2 



9 . Componente secondo la rivendicazione 7 o la 
rivendicazione 8, caratterizzato dal fatto che detto 
nucleo (RRP) d configurate per: 

- ricevere dati da detti moduli di interfaccia 
(RRI, DNSI, DII, Mil) ed estrarre da tali dati 
informazioni sullo stato delle cache e/o dei 
contenuti della rispettiva rete, 

- determ±nare I'esigenza di un aggiornamento di 
detti contenuti, e 
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realizzare detto aggiornamento effettuando 
altneno xin' operazione scelta, nel gruppo costituito 
da : 

- modifica della rispettiva base dati, 

- modifica delle tabelle del rispettivo servizio 
di directory name/ 

- modifica dell ' archivio dei rispettivi file di 
log, e 

inoltro di un messaggio con r:ichiesta di 
aggiornamento verso detto almeno tin componente 
omologo . 

10. Componente secondo una qualsiasi delle 
rivendicazioni 7 a 9, caratterizzato dal fatto che 
detto primo modulo di interfaccia (RRI) ^ 
configurate per comunicare con il primo modulo di 
interfaccia di detto almeno un componente omologo 
tramite protocollo CNAP. 

11. Componente secondo la rivendicazione 10, 
caratterizzato dal fatto che detto primo modulo di 
interfaccia (RRI) § configurate per realizzare la 
traduzione fra detto protocollo CNAP ed un format o 
comprensibile per detto nucleo (RRP) del rispettivo 
componente di interfaccia. 

12. Componente secondo una qualsiasi delle 
rivendicazioni 7 a 11, caratterizzato dal fatto che 
la comunicazione fra detto primo modulo di 
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interfaccia (RRI) e il primo modulo di interfaccia 
(RRI) di detto almeno un componente omologo 
comprende la trasmissione di segnali rappresentativi 
di grandezze scelte nel gruppo costituito da: 

- identif icativo della rete cui detto componente 
di interfaccia d associate, 

indirizzo IP della macchina ospitante il 
componente di interfaccia locale, 

identif icativi dei sistemi interconnessi 
tramite detto componente di interfaccia e detto 
almeno un componente di interfaccia omologo, 

- indirizzi IP dei componenti di interfaccia 
remoti di detti sistemi interconnessi in 
interlavoro , 

- livelli di confidenza del collegamento fra 
reti in interlavoro, e 

- almeno un dato identif icativo di almeno una 
carat teri St ica fisica, quale la distanza geografica, 
del collegamento fra detto componente di interfaccia 
e detto componente di interfaccia omologo. 

13. Componente secondo una qualsiasi delle 
precedenti rivendicazioni 7 a 12, caratterizzato dal 
fatto Che detto primo modulo di interfaccia (RRI) d 
configurate per realizzare lo scambio di 
informazioni con detto almeno un componente omologo 
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tramite im protocollo di trasporto IP quale il 
protocol lo TCP. 

14, Components secondo una qualsiasi delle 
precedent! rivendicazioni 7 a 13, carat terizzato dal 
fatto che detto nucleo (RRP) e detto primo modulo di 
inter faccia (RRI) scambiano segnali rappresentativi 
di grandezze scelte nel gruppo costituito da: 

- URL che identifica il contenuto a cui si 
riferisce il messaggio, 

- indirizzo IP della cache che distribuisce il 
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contenuto, ^ 

- identif icativo della rete content delivery ^ o 

O 5 

network proprietaria della cache, Z tU 

- State della cache, ^ 

ZD Z 

- State del contenuto presents in cache, e < 

tempo di vita dell ' inf ormazione di 
instradamento . 

15 • Componente secondo la rivendicazione 8/ 
caratterizzato dal fatto che detto quarto modulo di 
interfaccia (Mil) trasferisce verso detto nucleo 
(RRP) segnali rappresentativi di grandezze scelte 
nel gruppo costituito da: 

- indirizzo IP della cache cui si riferisce il 
messaggio, 

- percentuale di CPU utilizzata dalla cache, 

- percentuale di RAM utilizzata dalla cache. 
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percentuale di utilizzo dei dischi della 

cache , 

- percentuale del numero di utenti connessi in 
relazione alia capacita massima di servizio della 
cache coinvolta. 

16. Componente secondo la rivendicazione 8 o la 
rivendicazione 15, caratterizzato dal fatto che 
detto terzo modulo di inter faccia (DII) invia verso 
detto nucleo (RRP) segnali rappresentativi di 
grandezze scelte nel garuppo costituito da: 

URL che identifica il contenuto cui si 
riferisce il messaggio, 

- lista di indirizzi IP delle cache di detto 
contenuto, 

- livello di confidenza di detto contenuto, 

- disponibilita di detto contenuto, 

- stato della cache, 

tempo di vita dell ' inf ormazione di 
instradamento . 

17. Componente secondo la rivendicazione 16, 
caratterizzato dal fatto che detta grandezza 
identificativa del livello di confidenza del 
contenuto § suscettibile di ' assumere livelli 
distinti corrispondenti ad almeno un livello di 
confidenza scelto fra: 



- \in primo livello di confidenza, indicative del 
fatto che i contenuti possono essere scambiati con 
tutte le rati fra detto insieme di reti, 

- irn secondo livello di confidenza, indicative 
del fatto che detti contenuti possono essere 
scambiati solo con un sottoinsieme selettivamente 
deter-minato di reti comprese in detto insieme di 
reti - 

18 . Componente secondo una qualsiasi delle 
precedenti rivendicazioni 7 a 17, caratterizzato dal 
fatto che detto secondo modulo di interfaccia (DNSI) 
d configurate per poter comunicare con il server di 
directory name (DNS) per aggiomarne le rispettive 
tabelle sulla base di segnali rappresentativi di 
grandezze scelte nel gruppo costituito da: 

identif icazione dell ' operazione da eseguire 
sulla tabella di detto server, quale aggixmta e 
cancelLlazione , 

- tipo di registro, 

nome del dominio a cui si riferisce il 
messaggio 

- intero URL del contenuto a cui si riferisce il 
messaggio, 

- indirizzo IP della cache ottima per servire il 
suddetto dominio, 

- tempo di vita del registro. 





19. Componente secondo una qualsiasi delle 



fatto che detto modulo di nucleo comprende una 
memoria ospitante una struttura dati contenente 
informazioni relative alio stato della rispettiva 
rete di tipo content delivery network e delle reti 
omologhe collegate in interlavoro. 

II tut to sostanzialmente come descritto ed 
illustrate e per gli scopi specif icati. 



precedenti rivendicazioni 7 a 18, caratterizzato dal 
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